…ivate / auto-activate (#7428)

Resolves #7427(FR-2901)

Stacked on #7407.

## Summary

After mutations that change a deployment's `currentRevisionId` / `deployingRevisionId`, the Relay store's deployment record can fall out of sync with the server, causing the row tags in the revision history table and the Configuration Section's "current / deploying" panels to drift apart from what the server thinks. Two specific gaps were addressed:

- **`activateDeploymentRevision` (Revision History → Deploy)** — Mutation response previously returned only `deployment { id, currentRevisionId, currentRevision { id } }`. Extended to include `deployingRevisionId` and `...DeploymentRevisionDetail_revision` fragment on both `currentRevision` and `deployingRevision @SInCE(version: "26.4.3")`, so the normalized deployment record updates atomically. Consumers (`DeploymentDetailPage`, `DeploymentConfigurationSection`, `DeploymentRevisionHistoryTab` row tags) all share the same Relay store record and re-render on the next render pass.

- **`addModelRevision` (Add Revision modal, both Preset and Custom modes)** — Now that the backend exposes `ModelRevision.deployment` (lablup/backend.ai#11631 / BA-6056), the mutation reaches into `revision.deployment @SInCE(version: "26.4.4")` and selects `currentRevisionId`, `deployingRevisionId`, `currentRevision`, `deployingRevision`, so the deployment node is updated unconditionally on every revision add. No `autoActivate` branching — Relay normalizes the shared deployment node either way.
  - The previous client-side `fetchQuery` workaround helper is removed.
  - The `revision` selection itself was reduced to `id` + `...DeploymentRevisionDetail_revision`. The previously inlined fields (`resourceConfig.resourceOpts`, `modelRuntimeConfig.runtimeVariantId`, `modelDefinition.models[].service.preStartActions / shell / healthCheck.expectedStatusCode`, etc.) were dead selections — none of the response handlers read them, and the actual consumers (`AdminDeploymentPresetSettingPageContent`, `AdminDeploymentPresetModelConfigItem`, `DeploymentPresetDetailModal`) have their own queries.

- **`data/schema.graphql`** — Regenerated to add `ModelRevision.deploymentId: ID!` and `ModelRevision.deployment: ModelDeployment` per the merged backend PR.

## Test plan

- [ ] Open a deployment detail with multiple revisions in the Revision History tab. Click **Deploy** on a non-current revision → confirm the "Current" / "배포중" row tags AND the Configuration Section's `currentRevision` / `deployingRevision` panels both update without a manual refresh.
- [ ] From the same page open **Add Revision** modal in either Preset or Custom mode with **Auto activate ON** → submit → modal closes, success toast shows. Verify the Configuration Section moves to "deploying" state and the new revision appears as `deployingRevision` without a manual refresh.
- [ ] Same flow with **Auto activate OFF** → deployment record is still refreshed by the mutation (no autoActivate branching). `deployingRevisionId` typically stays unchanged on the server side; UI should show the new revision in history without an orphan "deploying" state.
- [ ] Backend lifecycle: leave the page idle while a deploying revision becomes current. The 5s `useInterval` polling in `DeploymentConfigurationSection` continues to work because `deployingRevision` is correctly populated immediately after the mutation.

## Backend dependency

Requires backend manager with [lablup/backend.ai#11631](lablup/backend.ai#11631) (BA-6056) — `ModelRevision.deployment` / `ModelRevision.deploymentId`. Older managers without the field will see the `@since(version: "26.4.4")` directive strip the field at request time, falling back to no auto-update for `addModelRevision` (the activate path is unaffected).